S3 をソースとする CodePipeline のトリガーにちょっとハマった話

S3 をソースとする CodePipeline のトリガーにちょっとハマった話

S3 へのオブジェクト配置をトリガーにしたパイプラインの実装でハマった場合に役に立つエントリです。
Clock Icon2023.02.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは!AWS事業本部コンサルティング部のたかくに(@takakuni_)です。

今回は S3 をソースとする CodePipeline がトリガーしなかった時に見るポイントをご紹介できればと思います。

おさらい

まずはじめに S3 をソースとしたパイプラインのスタート方法は、「ポーリング型」と「イベント型」の2種類があります。

2023年2月現在ではイベント型が推奨されており、具体的に以下のメリットがあります。

  • イベントは、平均して大幅に高速化されます。定期的なチェックが必要なポーリングとは異なり、イベントでは、発生直後にパイプラインを開始します。
  • 制限の引き上げ。変更をポーリングするパイプラインに比べて CodePipeline は、より多くのイベントベースのパイプラインをサポートできます。
  • 多数のパイプラインでのエクスペリエンスの向上。お客様によっては、多数のパイプラインでのコードの変更を調べるためにリポジトリを継続的にポーリングすることで、スロットリングまたはコストの増加が発生する場合があります。これらの問題はイベントを使用することで回避できます。

プッシュイベントを使用するようにパイプラインを編集する

そのため、本エントリは「イベント型」にフォーカスして、書いていこうと思います。

イベント型は、 Amazon EventBridge を使用した方式です。

EventBridge ルールでは、 AWS CloudTrail で検出された PutObject, CompleteMultipartUpload, CopyObject アクションでイベントをトリガーします。1

イベントがトリガーされると EventBridge に設定された IAM ロールを通じて対象のパイプラインに対してStartPipelineExecutionアクションを実行します。図にすると、次のイメージです。

EventBridge のルール忘れ

マネジメントコンソールから CodePipeline を作ると、 EventBridge に付与される IAM ロールや EventBrige のルールが自動的に作成されます。

自動で作成されている分、普段見えないため IaC で定義し忘れやすいリソースだと思います。

EventBridge ルール、 IAM ロールが正しく設定されていることを確認してみてください。

CloudFormation で作成する場合は、以下を参考に作成してみてください。2

CloudTrail を確認する

本エントリはここが本題です。

EventBridge問題ないな...アカウント変えたら動かなくなったぞ...

そんな方は、今すぐ CloudTrail の設定を確認してみましょう。

CloudTrailで S3 データイベントを取得していますか?

はい、そうです。 S3 がソースの場合は CloudTrail のデータイベントがイベントのトリガーに使われます。

CodeCommit や ECR を普段トリガーにしている場合は、 CloudTrail の管理イベントのみで問題ないのですが、 S3 がソースの場合はこの事象が起こります。

CloudTrail のデータイベントはデフォルトでは取得されないため、アカウントによって設定がさまざまです。

デフォルトでは、証跡はデータイベントを記録しません。追加の変更がイベントデータに適用されます。詳細については、「AWS CloudTrail 料金」を参照してください。

証跡のデータイベントの記録

また、別途料金がかかる機能のため、課金を最小限に抑えたい方は、「ソースバケットの対象オブジェクトのみ証跡を取る」ような詳細な設定も可能なためご検討ください。

(ちなみに、マネジメントコンソールで作成した場合、ソースバケット,オブジェクトに対してのデータイベントのみを取得する証跡が自動的に作成されていました。)

まとめ

以上、「S3 をソースとする CodePipeline のトリガーにちょっとハマった話」 でした。

EventBridge, IAM Role (EventBridge), CloudTrail (データイベント)の順にトラブルシューティングがおすすめです。

しっかりハマったため、ブログにしてみました。この記事がどなたかの参考になれば幸いです。

AWS事業本部コンサルティング部のたかくに(@takakuni_)でした!


  1. ドキュメントでは、PutObject, CompleteMultipartUpload アクションの2種類で記載されていましたが、マネジメントコンソールで作成したリソースは3種類のアクションをトリガーにしていたためコンソールを正として記載しています。(2023年2月現在) 
  2. 再掲になりますが、ドキュメントのアクションとマネジメントコンソールで作ったアクション数が異なります。マネジメントコンソールに合わせたい場合はCopyObject アクションもイベントのトリガーにしてください。 

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.